Show resource name in taint -allow-missing warning

Add name to untaint missing warning

Rather than using a prior value of null to indicate create, which is
imprecise because null is a valid output value, only plan values that
didn't exist in the prior state as Create changes.

…m-version-check-again

cli: Fix double check of remote workspace version

Create and Delete actions for output plans

I frequently see people attempting to ask questions about Terraform's
error and warning messages but either only copying part of the message or
accidentally copying a surrounding paragraph that isn't part of the
message.

While I'm sure some of these are just "careless" mistakes, I've also
noticed that this has sometimes overlapped with someone asking a question
whose answer is written directly in the part of the message they didn't
include when copying, and so I have a theory that our current output
doesn't create a good enough visual hierarchy for sighted users to
understand where the diagnostic messages start and end when we show them
in close proximity to other content, or to other diagnostic messages.
As a result, some folks fail to notice the relevant message that might've
answered their question.

I tried a few different experiments for different approaches here, such
as adding more horizontal rules to the output and coloring the detail
text differently, but the approach that felt like the nicest compromise
to me was what's implemented here, which is to add a vertical line
along the left edge of each diagnostic message, colored to match with the
typical color we use for each diagnostic severity. This means that the
diagnostics end up slightly indented from what's around them, and the
vertical line seems to help subtly signal how we intended the content
to be grouped together.

CI: Add broken link checking job for website content

Change the word "date" to "data"

Previously the state migration process was using the fallback strict
error check when migrating to or from a Terraform Cloud workspace. This
resulted in an error when running init if the local and remote Terraform
versions did not exactly match.

This was excessively strict. When migrating from a remote Terraform
Cloud workspace to local state, there is no need for a version check at
all, as we cannot break the Terraform Cloud workspace. When migrating
to Terraform Cloud, we should use the more forgiving check, rather than
the strict equality.

This commit fixes both of these cases accordingly, and allows migrating
state to and from Terraform Cloud remote workspaces without errors.

InitProvisioner only stored the provisioner in the cache and provided a
way to return an error. We can push this back further into the cli init
process, but for now we can move the error into the Provisioner call and
drop InitProvisioner.

This also changes CloseProvisioner to CloseProvisioners, in preparation
for the removal of the graph nodes.

Provisioners are always run via a single instance, and their
configuration and references are taken care of via their parent
resource, so there is no need to maintain the provisioner graph nodes.

The only action that will still need to be completed is calling the
Close method for external plugins. This was not consistently done with
the current handling of provisioners anyway, and we can now add that to
a single point with the new CloseProvisioners context method.

This was not done consistently in all cases when the individual
provisioner graph nodes were used. Since we removed the graph nodes, the
only thing left is to close these at the end of the walk.

Provisioner lifecycle

…ion-check-state-migration

cli: Fix state migration remote version check

Move remaining helper/ packages to internal/

The existing context test files are becoming quite unwieldy.
Start new ones both to make editing easier, and to help discourage the
copy+pasting of older test patterns we no longer need.

The tainted state was checked against `cty.NilVal`, however it was
always being set to a null value.

The refreshed state value was being shadowed, and not used in the
following plan.

Error planning tainted resource when it no longer exists

When planning a data source change, the object compatibility
verification step should be performed with unmarked values. This value
is transient and preserving marks is not necessary, and the object
change code is not fully marks-aware.

This is just a prototype to gather some feedback in our ongoing research
on integration testing of Terraform modules. The hope is that by having a
command integrated into Terraform itself it'll be easier for interested
module authors to give it a try, and also easier for us to iterate quickly
based on feedback without having to coordinate across multiple codebases.

Everything about this is subject to change even in future patch releases.
Since it's a CLI command rather than a configuration language feature it's
not using the language experiments mechanism, but generates a warning
similar to the one language experiments generate in order to be clear that
backward compatibility is not guaranteed.

Since this is still at an early phase and likely to change significantly
in future iterations, rather than attempting to guess on a suitable final
location for documenting the testing feature I've instead taken the
unusual approach of adding a new page that is explicitly about the
experiment. My expectation is that once we conclude the experiment we'll
replace this new page with a stub that just explains that there was once
an experiment and then links to whatever final feature unfolded from the
research.

The URL for this page is hard-coded into the warning message in the
"terraform test" command, so as we continue to evolve this feature in
future releases we'll need to update the callout note on the page about
which Terraform CLI version it's currently talking about, so users of
older versions can clearly see when they'd need to upgrade in order to
participate in a later incarnation of the experiment.

cli: Migrate refresh to command views

The auto-approve argument was part of the arguments.Operation type,
which resulted in adding a silent -auto-approve flag to plan and
refresh. This was unintended, and is fixed in this commit by moving the
flag to the arguments.Apply type and updating the downstream callers.

cli: Migrate plan to command views

Instead of returning an error with no context about unexpected
attributes or incorrect types, notify users that the schema stored in
the state does not match the current provider.

User can only encounter this error if the providers have updated their
schemas since the state was stored. This would appears when running
`terraform show -json` to display the current state, or
`terraform show -json planfile` if that plan was created with
`-refresh=false`. In either case, the state must be refreshed in order
to properly json encoded.

Provider transformer cleanup

Although we don't typically do configuration-level string wrangling
directly in Terraform, we delegate to several other upstream libraries
that do. These upgrades all switch to newer versions that support the
latest definitions from Unicode 13, primarily affecting operations such
as converting strings to upper/lowercase or splitting strings into
component characters (substr, reverse, etc).

The tests for the upstream libraries didn't show any regressions from
these updates, so the Unicode 13 changes seem to be backward-compatible
additions rather than significant breaking changes.

(Our go.mod file had also become non-canonical in some ways, and the Go
toolchain fixed that as part of this work, causing a few extra style-only
diffs here that shouldn't cause any change in behavior.)

jsonstate: indicate schema version mismatch during encoding

Add State Learn tutorial to State docs

Document `inline` & `on_failure` behaviour

cli: Add reference to global options to help text

* Update Godoc links from godoc.org to pkg.go.dev

* Update reference to renamed GraphNodeResource interface

Ref #24389

* Update dead links; minor formatting adjustments

* Add FIXME item following deprecation of EvalNode

…esourceConfig (#27874)

* providers.Interface: rename ValidateDataSourceConfig to
ValidateDataResourceConfig

This PR came about after renaming ValidateResourceTypeConfig to
ValidateResourceConfig: I now understand that we'd called it the former
instead of the latter to indicate that the function wasn't necessarily
operating on a resource that actually exists. A possibly-more-accurate
renaming of both functions might then be ValidateManagedResourceConfig
and ValidateDataResourceConfig.

The next commit will update the protocol (v6 only) as well; these are in
separate commits for reviewers and will get squashed together before
merging.

* extend renaming to protov6

Catch attributes which are planed but not computed separately to provide
a clearer error to provider developers.

The error conditions were previously caught, however it was unclear from
the error text as to _why_ the change was an error. The statements about
value inequality would be incorrect when planning no changes for a value
which should not have been set in the first place.

#27904)

this fixes a bad merge on my part

These flags are not used and have been deprecated since 0.12.11.

As usual, we'll continue to iterate on this based on feedback and
questions during the beta period, but this is a first draft intended to
help those who are trying out the first beta.

…m-validate

cli: Remove -var/-var-file flags from validate

objchange: catch invalidly planned attributes earlier